NPfIT Message Data types
	Programme	NPFIT	DOCUMENT NUMBER
	Sub-Prog/Project	Comms & Messaging	NPFIT-FNT-TO-DPM-0602
	Prog. Director	Paul Jones
	Sub-Prog/Proj Mgr	Ken Lunn
	Author	C&M Development  Team	Version No.	3.1
	NPO/PSO Contact	Richard Kavanagh	Status	Issued

 

 

Contents

 

 

 

 

Change History

 

In Version	Author	Date	Amendment Details
0.1	Core Technical Team	27/10/2003	First draft for review
0.2	Core Technical Team	24/11/2003	Update following feedback. final draft prior to publication
1.0	Core Technical Team	28/11/2003	Format and typographic changes for final version
1.1	Core Technical team	24/12/2003	HV address use type replaced by TMP
1.2	Core Technical Team	29/12/2003	Updated for PDS requirements
2.0	Core Technical Team	13/02/2004	Time examples revamped to conform with latest HL7 v3 standard. Name and address changed to conform with latest PDS requirements. Communication address changed to conform with latest PDS requirements. Reference to HL7 v3 material added to document.
2.0.1	D Markwell	04/06/2004	Updated to take account of HL7 UK comments on alignment with HL7 V3 standard datatypes. Also includes pre-adoption of group element in the Concept Descriptor data type to support SNOMED CT role grouping.
2.1	Core Technical Team	25/06/2004	Additional datatype flavour of CV Coded with Code System). Minor error corrections. Addition of example XML fragments.
2.2	Core Technical Team	20/08/2004	Note against BN datatype indicating that its use is deprecated. Correction to the spelling of "separatable" to match HL7 spelling ("seperatable") in some example data. Correction to example related to datatype flavor "Date or Time Interval After" (removal of erroneously present <high> element).
2.3	Core Technical Team	06/12/2004	Change request MIM-CR-0279. Typographical corrections in sections 2.8.1 and 2.8.2: references to IVL<PQ> corrected to IVL<TS>. Also reference to valid constraint of TS removed from section 2.8.2.1.
2.4	Core Technical Team	7/1/2005	Added  Encapsulated Data Limited HTML (f) plus examples and link to an explanatory document.
2.5	Core Technical Team	31/3/2005	Change Request MIM-CR-0446. Amended to use correct default OID for SNOMED CT. Emphasized link to XHTML Document by creating another sub heading. Added extra examples for the Encapsulated Data Attachment Reference flavor.
2.6	C & M development team	30/09/2005	Added descriptions of ED presentation text data type flavour.Added description for TN data type.
2.7	C & M development team	16/12/2005	Changed descriptions of ED presentation text data to make clearer and fixed incorrect link.
2.8	C & M development team	28/02/2006	Added reference to the new flavour of ED ED.NPfIT.Text.XHTML
2.9	C & M development team	28/02/2006	Updated definitions of Physical Quantity flavours Quantity in Alternative Units and Quantity in Arbitrary Units.
3.0	C & M development team	16/08/2006	Updated xmlns attribute of PresentationText XHTML flavour to "xhtml:NPfIT:PresentationText"
3.1	C & M development team	31/10/2006	Change request CR-0541: Added address use type 'H'. Removed references to plain text in presentation text as used by GP summary.

 

 

1    Introduction

1.1    National Programme for Information Technology (NPfIT) Data Types

The messages designed to support NPfIT clinical messages specify a data type for each data item.  There is an XML representation of each data type, and the schemas for these are in the file datatypes.xsd. For two attributes, (Address part type of element ADXP), as permitted by HL7 V3 regulations, UK-specific attribute values have been used rather than the standard HL V3 set.

 

The data types listed below are a subset of the full HL7 V3 data types as these were defined in August 2003 prior to the fifth ballot.  While there may be differences between the data types defined here and the final HL7 balloted data types, it is anticipated that there will be an XSLT transform that can be applied to convert the data types described below to the final HL7 V3 ones.  For the full HL7 v3 Ballot 6 (Jan 2004) documentation on data types, readers should consult the HL7 v3 Ballot pack.

 

The data types have been described in this document to prevent the ongoing HL7 ballot process from introducing uncertainty to NPfIT, and to allow NPfIT-specific profiles of each data type, with only those values that are appropriate in the context of NPfIT.  This will simplify the processing requirements for the receiving systems, and remove the need for developers to learn about optional facets of the data types that are not being used in NPfIT messages.

 

1.2    HL7 and W3C data types

All HL7 data types are based on the data types defined in the W3C schema recommendation.  However the HL7 data types were defined as those best suited to meet the requirements of healthcare messaging and this accounts for some of the differences between them and the native W3C XML Schema data types.

Some simple data types such as Boolean are restrictions on the W3C version, with the values "true and "false" being allowed, but not 0 and 1, which have proved a source of confusion in messaging implementations.  Others are more loosely defined, such as TS (Time Stamp) which is implemented as a union of many of the W3C date/time data types.

Where a data type component is intended to be used externally its name is in capitals (e.g. TS), and where is intended only for use in as a part of another data type, the name is in lower case (e.g. center, low and high which is used by IVL_TS).

 

1.3    Data type flavours

HL7 Version 3 provides a rich set of possible variants on a set of relatively complex data types. For the purposes of NPfIT this document describes constraints on some of the HL7 Data Types. Each profile of a data type is referred to as a "flavour". Each of the permitted "flavours" is specified in full and is assigned a name which is used in guidance documents to indicate which variant to use to meet particular sets of requirements. This approach is experimental - in the sense that it is not part of standard HL7 methodology. Its principal purpose is to enumerate the possible structures and simplify advice on the most appropriate way to represent specific collections of data. Similar issues have been raised in the HL7 community and specifications such as this may become common within particular realms of use.  Data type flavour titles are suffixed with (f).

 

1.4    SET, LIST, BAG and IVL

These are data values that comprise generic collections of data values of a single data type.  Four concern us here:

• BAG – unordered collection of data values.  A data value may occur more than once.  The collection of the integers (17, 2,13, 2, 99,17) would be a BAG.
• LIST – an ordered collection of distinct data values. The collection of the integers (2, 13, 17, 99) would be a LIST.
• SET – a collection of distinct data values in no particular order. The collection of the integers (17, 13, 99, 2) would be a SET.
• IVL - a set of consecutive values.

                IVL<TS> an interval of Points in Time

                IVL<PQ> an intveral of Physical Quantities

 

 

2    Data Type details

 

2.1    Any (ANY)

 

An element of the abstract type ANY may be any one of the other data types listed below, such as BL, ST, CV, PQ, TS, etc.  It shall be resolved to one of the more specific data types when an instance of a message using it is generated.  This represents the global HL7 standard, and is not an NPfIT flavour 

 

2.2    Simple types

2.2.1    Boolean (BL)

An element of type BL has one attribute, a "value" which shall be "true" or "false". Alternatively, the "nullFlavor" attribute may be used to indicate that a simple true or false value cannot be asserted. This represents the global HL7 standard, and is not an NPfIT flavour. 

 

Note: The values are case sensitive (e.g. "TRUE" is not a valid value but "true" is).

 

Note: A nullFlavor is not permitted simultaneously with a value.

 

Examples:

 

<!-- To indicate a context conduction indicator with value "true" -->

<contextConductionInd value="true"/>

 

<!-- To indicate a seperatable indicator with value "false" -->

<seperatableInd value="false"/>

 

<!-- To indicate a seperatable indicator where the value is unknown -->

<seperatableInd nullFlavor="UNK"/>

 

2.2.2    BooleanNonNull (BN)

An element of type BN constrains the data type BL.  It has one attribute, a "value" which shall be "true" or "false". This represents the global HL7 standard, and is not an NPfIT flavour.

 

Note: The values are case sensitive (e.g. "TRUE" is not a valid value but "true" is).

 

Note: A nullFlavor is not permitted with this datatype.

 

Note: Use of this datatype is deprecated as a non-null restriction can be indicated by making a class or attribute in HL7 models mandatory (where null flavors are not applicable).

 

Examples:

 

<!-- To indicate a context conduction indicator with value "true" -->

<contextConductionInd value="true"/>

 

<!-- To indicate a seperatable indicator with value "false" -->

<seperatableInd value="false"/>

 

2.2.3    Integer Number (INT)

Integers are expressed as an attribute "value" within this data-type.  Where the value is not known or not available then an appropriate setting for the "nullFlavor" attribute should be sent. This represents the global HL7 standard, and is not an NPfIT flavour.

 

Note: A nullFlavor is not permitted simultaneously with a value.

 

Examples:

 

<!-- To indicate a repeat number of "1" -->

<repeatNumber value="1"/>

 

<!-- To indicate a sequence number where the value is unknown -->

<sequenceNumber nullFlavor="UNK"/>

 

2.2.4    Real or Decimal Number (REAL)

Fractional numbers are expressed as an attribute "value" within this data-type.  Where the value is not known or not available then an appropriate setting for the "nullFlavor" attribute should be sent. This represents the global HL7 standard, and is not an NPfIT flavour.

 

Note: A nullFlavor is not permitted simultaneously with a value.

 

Examples:

 

<!-- To indicate a value of "2.3" -->

<value value="2.3"/>

 

<!-- To indicate that the value is unknown -->

<value nullFlavor="UNK"/>

 

2.3    Text and encapsulated data

2.3.1    Character String (ST)

String data is sent as the element content for any element of this datatype. This represents the global HL7 standard, and is not an NPfIT flavour.

 

Note: A nullFlavor is not permitted simultaneously with a value.

 

Examples:

 

<!-- To indicate some plain text (in an observation class "text" attribute) -->

<text>Some plain text</text>

 

<!-- To indicate that the text value is unknown (in an observation class "value" attribute) -->

<value nullFlavor="UNK"/>

 

2.3.2    Character String with Code (SC)

A character string that optionally may have a code attached. The text must always be present if a code is present. The code is often a local code.

 

Note: A nullFlavor is not permitted simultaneously with a value.

 

Examples:

 

<!-- To indicate a software name of "NHAIS" -->

<softwareName>NHAIS</softwareName>

 

<!-- To indicate a software name of "NHAIS" and a code meaning "NHAIS" -->

<softwareName code="1" codeSystem="2.16.840.1.113883.2.1.3.2.9999" displayName="NHAIS">NHAIS</softwareName>

 

<!-- To indicate that the software name is unknown-->

<softwareName nullFlavor="UNK"/>

 

2.3.3    Encapsulated Data (ED)

ED is used to hold encapsulated data, which is anything that is not expressed directly in an HL7 data type. There are only three attributes allowed -- "encoding" which can only be "B64" (base64) or "TXT" (Text, which is the default value), "mediaType" which identifies the MIME type of the data, and “compression” which indicates the algorithm (if any) used to compress the data.  A full list of the supported types is provided in the HL7 specification document.

Where the data is included in the element, it is sent as the element content.  Alternatively it can be sent as a URL using the optional "reference" child.  If this reference element is used, then there should not be any other content in the ED-typed element (i.e. data must either be sent inline, or by reference, but both should not be done at the same time).  The reference element is of type TEL, with attributes for the URL, the use type, and an optional valid Time child element to specify when the linked data is useable.

 

1 data	The text or data (may be null with reference to get data)
0..1 encoding	Binary encoding = "TXT" (Text - default) or "B64" (Base 64)
0..1 mediaType	MIME media type = "text/plain" (default) or other MIME media types
0..1 reference	URL reference to data
0..1 compression	Code representing compression used if any "DF"=deflate or "GZ"=zip as in HL7 specification.
Components not used here include "integrityCheck","integrityCheckAlgorithm", "xml:lang","thumbnail"

 

Flavours of ED

 

• Encapsulated Data Plain Text (f)

• Encapsulated Data Text and Line Breaks (f)

• Encapsulated Data Limited HTML (f)

• ED.NPfIT.Text.XHTML

  • Encapsulated Data Presentation Text XHTML(f)

• Encapsulated Data Attachment Reference (f)

• Encapsulated Data Attachment (f)

 

2.3.3.1        Encapsulated Data Plain Text (f)

The default type with plain text only. In practice this is represented as though it were of data type ST

 

1 data

The text.

 

Examples:

 

<!-- To indicate some encapsulated data plain text (in an observation class "value" attribute) -->

<value>Some plain text</value>

 

Back to ED index

 

2.3.3.2                Encapsulated Data Text and Line Breaks (f)

 

A use of text which explicitly includes use of fixed font, maintained white space and hard line breaks. Designed to meet the need for compatibility with UK NHS PMIP tabular text formats.

 

Any TAB characters should be converted to the requisite number of spaces in this format.

• This format may be converted to HTML for rendering by enclosing it in the element <pre> and conversion of HTML special characters (e.g. < > &) to the appropriate entities.

 

1 data	The text
1 mediaType	"text/x-h7uk-pmip"

 

Back to ED index

2.3.3.3                        Encapsulated Data Limited HTML (f)    Note - Not for use with Presentation Text.

A restricted version of the HL7 CDA-Level 1 and is compatible with XHTML. Designed for use with formatted marked up documents.

 

 

 

1 data	The text
1 mediaType	"text/x-h7uk-html"

 

Examples:

 

<!-- To indicate simple formatting such as paragraph breaks plus a document title-->

<value mediaType="text/x-h7uk-html" >
 <html xmlns="http://www.w3.org/1999/xhtml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/1999/xhtml ..\dt\xhtmlNPfIT.xsd">
 <head>
 <title>Diagnostic Imaging Procedure Report</title>
 </head>
 <body>
 <p>The lung fields are clear. Heart size is enlarged
 with slight unfolding of the aorta.</p>
 <p>CTR = 18/35 cm</p>
 <p>The right hemi-diaphragm is raised</p>
 </body>
 </html>

</value>

 

2.3.3.3.1 XHTML Specification

A more detailed explanation of XHTML usage is available in Message constraints for the ED Datatype.

 

Back to ED index

2.3.3.4                        Encapsulated Data Presentation Text XHTML(f)

A restricted version of HTML. Designed for use with formatted marked up documents. This flavour carries a mediaType Attribute which is mandatory and has a fixed value of "text/plain". The default character set for XHTML is UTF-8.

 

1 data	The text
1 mediaType	"text/plain"

 

Examples:

 

<!-- To indicate simple formatting such as paragraph breaks -->

<value mediaType="text/plain" >
 <html xmlns="xhtml:NPfIT:PresentationText">
 <head>
 </head>
 <body>
 <p>The lung fields are clear. Heart size is enlarged
 with slight unfolding of the aorta.</p>
 <p>CTR = 18/35 cm</p>
 <p>The right hemi-diaphragm is raised</p>
 </body>
 </html>

</value>

 

A more detailed explanation of usage is available in Message constraints for the ED Datatype when used with presentationText.

 

Back to ED index

2.3.3.5                        Encapsulated Data Attachment Reference (f)

Used to represent a reference to attached data either elsewhere in the message or at some other accessible location.

 

1 data	Null
0..1 mediaType	MIME media type of the referenced data.
1 reference	URL reference to data
0..1 compression	Code representing compression applied to the referenced data.

 

Examples:

 

<!-- To indicate an attachment reference (in an observation class "value" attribute) -->

<value>

     <reference value="http://www.nhsia.nhs.uk/MIMv3.0/index.htm"/>

</value>

 

<!-- To indicate an attachment reference to a JPEG image (in a DGIMG class "value" attribute) -->

<value mediaType="image/jpeg">

     <reference value="http://www.hospital-stmarco/radiology/wado/0123456.jpg"/>

</value>

 

<!-- To indicate an attachment reference to a GZ compressed file (in an observation class "value" attribute) -->

<value compression="GZ">

     <reference value="http://www.w3.org/Library/Distribution/w3c-libwww-5.4.0.tgz"/>

</value>

 

Back to ED index

2.3.3.6                       Encapsulated Data Attachment (f)

Used for conveying attachments within a message. Note that text should be conveyed in one of the other variants noted above.

 

1 data	The binary data encoded in Base 64
1 encoding	"B64"
1 mediaType	MIME media type of the encoded data
0..1 compression	Code representing compression used in the attached data.

 

Examples:

 

<!-- To indicate attachment data (in an observation class "value" attribute) -->

<value encoding="B64" mediaType="text/plain">[BASE64REPRESENTATIONOFTHEDATA]</value>

 

Back to ED index

2.4    Demographics

 

2.4.1    Person Name (PN)

Person Name is used to express either an unstructured name as string content of the element, or a structured name as a set of FAM, GIV, PFX and SFX child elements. If any of the FAM, GIV, PFX and SFX elements are used, then there shall be no string content in the PN-typed element (i.e. the name must be structured or unstructured). In a structured name there may be only one FAM element for the family name, and one PFX element for the title.  The text values of the FAM, GIV, PFX and SFX elements shall be sent as element content. If the name is available in both structured and unstructured forms, the structured form shall be preferred.

 

For both structured and unstructured names, there are two optional additional elements:-

the use of the name may be sent as a single optional attribute ("use") of the PN-typed element with seven possible values: L = usual (current) name, A = alias name, PREFERRED, PREVIOUS-BIRTH, PREVIOUS-MAIDEN, PREVIOUS-BACHELOR and PREVIOUS

• a validTime IVL<TS> child element can be used to define the timeframe within which this name is valid, e.g. when the current name was assigned or the period during which a previous name was valid

 

The flavours possible are therefore:

1.     Person name unstructured  (f)

2.     Person name unstructured with use (f)

3.     Person name unstructured with valid time (f)

4.     Person name unstructured with use and valid time (f)

5.     Person name structured (f)

6.     Person name structured with use (f)

7.     Person name structured with valid time (f)

8.     Person name structured with use and valid time (f)

 

2.4.1.1                        Person Name Unstructured with optional Use and optional Valid Time (f)

1 ST	Text of the name This is represented as a simple string data type ST
0..1 use	HL7 standard name types supported by NPfIT: "L" - Usual (current) name "A" - Alias name   NPfIT additions to the set of HL7 standard name types (NPfIT will be pursuing getting these [or suitable equivalents] added into the HL7 standard): "PREFERRED" - Preferred name "PREVIOUS-BIRTH" - Birth name "PREVIOUS-BACHELOR" - Bachelor name "PREVIOUS-MAIDEN" - Maiden name "PREVIOUS" - Other previous name
0..1 validTime IVL<TS>	The period of validity of the name is specified using one of the following flavours of the IVL<TS> data type: Time Point - where known to be valid at a specified date. Time Interval Complete - where the start and end of the period of validity is known. Time Interval Before - where the end of the period of validity is known. Time Interval After - where the start of the period of validity is known.

 

Examples:

 

<!-- To indicate an unstructured usual person name -->

<name use="L">John Smith</name>

 

<!-- To indicate an unstructured alias person name with a validity date interval -->

<name use="A">John Smith

     <validTime>

          <low value="19990401"/>

          <high value="20040331"/>

     </validTime>

</name

2.4.1.2                        Person Name Structured with optional Use and optional Valid Time (f)

1..* ENXP	1 type	"family", "given", "prefix" or “suffix”
	1 data	Text of the name part
0..1 use	HL7 standard name types supported by NPfIT: "L" - Usual (current) name "A" - Alias name   NPfIT additions to the set of HL7 standard name types (NPfIT will be pursuing getting these [or suitable equivalents] added into the HL7 standard): "PREFERRED" - Preferred name "PREVIOUS-BIRTH" - Birth name "PREVIOUS-BACHELOR" - Bachelor name "PREVIOUS-MAIDEN" - Maiden name "PREVIOUS" - Other previous name
0..1 validTime IVL<TS>	The period of validity of the name is specified using one of the following flavours of the IVL<TS> data type: Time Interval Complete - where the start and end of the period of validity is known. Time Interval Before - where the end of the period of validity is known. Time Interval After - where the start of the period of validity is known.

 

 Examples:

 

<!-- To indicate a structured usual person name with title, two forenames, family name and suffix -->

<name use="L">

     <prefix>Mr</prefix>

     <given>John</given>

     <given>Paul</given>

     <family>Smith</family>

     <suffix>Snr</suffix>

</name>

 

<!-- To indicate a structured usual person name with title, two forenames, family name and suffix, with a validity date interval -->

<name use="A">

     <prefix>Mr</prefix>

     <given>John</given>

     <given>Paul</given>

     <family>Smith</family>

     <suffix>Snr</suffix>

     <validTime>

          <low value="19990401"/>

          <high value="20040331"/>

     </validTime>

</name>

 

2.4.2    Organization Name (ON)

2.4.3    Trivial Name (TN)

A restriction of entity name that is effectively a simple string used for a simple name for things and places.

The TN is a EN that consists of only one name part without any name part type or qualifier. The TN, and its single name part are therefore equivalent to a simple character string. This equivalence is expressed by a defined demotion to ST and promotion from ST.

Examples:

 

Trivial names are typically used for places and things, such as Lake Erie or Reagan National Airport:

 

<name>Lake Erie</name>

 

<name>Washington National Airport</name>

 

2.4.4    Postal Address (AD)

The element is defined as holding mixed content. An address shall be transmitted in one of four formats:

unstructured address, transmitted as up to 175 characters of text without any further markup structure, i.e. as string content of the AD element.  This corresponds to the NHS Data Dictionary Unstructured Address, address format code = “U” or “2”.

an address as a set of print lines, transmitted as 1 to 5 child ADXP elements of type “streetAddressLine” and maximum length 35 characters.  This corresponds to the NHS Data Dictionary Label Format Address, address format code = “S” or “1”, and UK Government Data Standards catalogue UK Postal Address.

address as a set of typed parts, transmitted as a set of typed child ADXP elements.  This corresponds to a subset of the UK Government Data Standards Catalogue BS7666 Address, which will be incorporated the NHS Data Dictionary when it has moved from draft to final status.  It is because of the draft status that the BS7666 Address Unique Property Reference Number and Unique Street Reference Number have not been included yet.

as a unique identifier for the address, used where the recipient does not need to receive the full address (for example because the receiving application has access to an address file keyed by the unique identifier).  The key currently used in NPfIT is the Postal Address File (PAF) key, which is generated by the Royal Mail.

In all cases, the components and content shall be ordered in the sequence in which they are to be printed, i.e. reading left to right and top to bottom.

 

If an address is available in more than one of formats 1-3, and a message permits more than one format, the most structured version available should be used, i.e. format 3 should be used wherever possible, failing that format 2, and failing that format 1. 

 

An optional postcode may be specified for any of the first three address formats in a child “postalCode” element.

 

AD has a single optional attribute "use" that may be used to specify the purpose of the address.  The permitted values are "H" (Home Address, NHS Data Dictionary Main permanent residence - value "a"), “HP” (Primary Home, NHS Data Dictionary Main permanent residence - value “a”), “TMP” (Temporary Address, NHS Data Dictionary Temporary residence - value “c”), “PST” (Postal Address, NHS Data Dictionary Correspondence [Non-Residence] - value “d”) and “WP” (Work Place, NHS Data Dictionary Main business premises - value “e”).

 

An optional child element, validTime, may be used to define a time interval within which this address is valid.  See IVL<TS> below for a description of this element's type.

 

A unique address identifier used on its own shall not be accompanied by a “use” or “validTime”.

 

There are therefore eight valid flavours of unstructured address (format 1):

1.     Unstructured Address (f)

2.     Unstructured Address plus postal code (f)

3.     Unstructured Address plus use  (f)

4.     Unstructured Address plus valid time (f)

5.     Unstructured Address plus postal code and use (f)

6.     Unstructured Address plus postal code and valid time  (f)

7.     Unstructured Address plus use and valid time (f)

8.     Unstructured Address plus postal code and use and valid time  (f)

 

For partially and fully structured addresses (formats 2 and 3), there are now 32 flavours of each when all permutations of the optional elements are allowed for.

 

2.4.4.2    Address streetAddressLine Typed, plus optional Postcode, optional address key, optional description, optional Use and optional useable period. (f)

Flavours of this format (format 2) is used for addresses which are structured into print lines.  It is up to the transmitter to decide which address elements appear on which line.

 

1..5 ADXP	1 type	Shall be "streetAddressLine".
	1 data	Text of the address part, excluding any markup characters intended to control layout. No fixed abode shall be represented by one address line containing the text “no fixed abode”
0..1 ADXP	1 type	“postalCode"
	1 data	UK format Postcode No fixed abode shall be recorded with the appropriate code (ZZ99 3VZ). The 8 characters field allows a space to be inserted to differentiate between the inward and outward segments of the code, enabling full use to be made of Royal Mail postcode functionality.
0..1 ADXP	1 type	“addressKey"   NB This address part type is an NPfIT addition to the HL7 standard set of address part types, and NPfIT will propose its addition to the HL7 standard.
	1 data	A unique identifier keyed to Royal Mail Postal Address File (PAF) Directory.
0..1 ADXP	1 type	“desc"   NB: This is a temporary NPfIT addition to the HL7 standard set of address part types, and is likely to be replaced at some point in the future once a suitable alternative mechanism is found for carrying this data.
	1 data	Textual description of the usage of a temporary address.
0..1 use	HL7 standard address use types supported by NPfIT: "H" - Home address "HP" - Primary home "TMP" -Temporary address “PST” - Correspondence address “WP” - Work address
0..1 useablePeriod IVL<TS>	The period of validity of the address shall be specified using one of the following flavours of the IVL<TS> data type: Time Interval Complete - where the start and end of the period of validity is known. Time Interval Before - where the end of the period of validity is known. Time Interval After - where the start of the period of validity is known.

 

  

2.4.4.3    Address fully structured, plus optional Postcode, optional address key, optional description, optional Use and optional useable period. (f)

A fully structured (format 3) address consisting of a collection of typed parts, identifying components such as the building, street, locality and town.  The part type “delimiter” may be used to control line spacing.  The parts shall occur in the order in which they are to be printed.

 

1..5 ADXP	1 type	The type shall be one of the following, which replace the HL7 standard types for UK use: “POB” - post box number “ADP" - address prefix, e.g. location within a building or complex, such as “Flat 22”. Similar to HL7 “UNID” “BI” - building identifier, e.g. house name or number”. Broader version of HL7 “BNR” “STR” - street or road name.  HL7 standard “LCY” - locality. A refinement of HL7 “CTY” “TN” - town. A refinement of HL7 “CTY” “CPA” - county. HL7 standard “CNT” - country. HL7 standard “delimiter”. Only one of each type (other than a delimiter) may occur in an address, and one “buildingIdentifier” part shall be present.  If “poBox” is used, “address prefix” may not be used.
	1 data	Text of the address part, excluding any markup characters intended to control layout. No fixed abode shall be represented by one address line containing the text “no fixed abode”
0..1 ADXP	1 type	“postalCode"
	1 data	UK format Postcode No fixed abode shall be recorded with the appropriate code (ZZ99 3VZ). The 8 characters field allows a space to be inserted to differentiate between the inward and outward segments of the code, enabling full use to be made of Royal Mail postcode functionality.
0..1 ADXP	1 type	“addressKey"   NB This address part type is an NPfIT addition to the HL7 standard set of address part types, and NPfIT will propose its addition to the HL7 standard.
	1 data	A unique identifier keyed to Royal Mail Postal Address File (PAF) Directory.
0..1 ADXP	1 type	“desc"   NB: This is a temporary NPfIT addition to the HL7 standard set of address part types, and is likely to be replaced at some point in the future once a suitable alternative mechanism is found for carrying this data.
	1 data	Textual description of the usage of a temporary address.
0..1 use	HL7 standard address use types supported by NPfIT: "H" - Home address "HP" - Primary home "TMP" -Temporary address “PST” - Correspondence address “WP” - Work address
0..1 useablePeriod IVL<TS>	The period of validity of the address shall be specified using one of the following flavours of the IVL<TS> data type: Time Interval Complete - where the start and end of the period of validity is known. Time Interval Before - where the end of the period of validity is known. Time Interval After - where the start of the period of validity is known.

 

2.4.4.4    Address identifier. (f)

This (format 4) consists of a single unique address identifier

 

1 ADXP	1 type	“addressKey"   NB: Please note that this address part type is an NPfIT addition to the HL7 standard set of address part types, and NPfIT will be pursuing getting it (or a suitable equivalent) added into the HL7 standard.
	1 data	A unique identifier that is a valid entry in the Royal Mail Postal Address File (PAF) Directory.

 

 Examples:

 

<!-- To indicate a home address with unstructured address lines -->

<addr use="H">

     <streetAddressLine>Hexagon House</streetAddressLine>

     <streetAddressLine>Pynes Hill</streetAddressLine>

     <streetAddressLine>Rydon Lane</streetAddressLine>

     <streetAddressLine>Exeter</streetAddressLine>

     <streetAddressLine>Devon</streetAddressLine>

     <postalCode>EX2 5SE</postalCode>

     <addressKey>12345678</addressKey>

</addr>

 

<!-- To indicate a temporary address with unstructured address lines and a description and dates -->

<addr use="TMP">

     <streetAddressLine>AQUEOUS II</streetAddressLine>

     <streetAddressLine>ASTON CROSS</streetAddressLine>

     <streetAddressLine>ROCKY LANE</streetAddressLine>

     <streetAddressLine>ASTON</streetAddressLine>

     <streetAddressLine>BIRMINGHAM</streetAddressLine>

     <postalCode>B6 5RQ</postalCode>

     <addressKey>23456789</addressKey>

     <desc>Holiday home</desc>

     <useablePeriod>

          <low value="20040716"/>

          <high value="20040831"/>

     </useablePeriod>

</addr>

 

<!-- To indicate a home address with structured address lines -->

<addr use="H">

     <houseNumber>Hexagon House</houseNumber>

     <streetName>Pynes Hill</streetName>

     <streetName>Rydon Lane</streetName>

     <city>Exeter</city>

     <county>Devon</county>

     <postalCode>EX2 5SE</postalCode>

     <addressKey>12345678</addressKey>

</addr>

 

2.4.5    Telecommunication Address (TEL)

Telephone numbers, pager and email addresses, and references to external data by the ED data type are all expressed using the URL syntax as described in the HL7 documentation.  Note that specification of the type of the address (e.g. fax or email) is built into the URL itself. 

There are two optional components of Telecommunication Address::

• The codes for the "use" attribute are limited to the following list for the purposes of this project: HP (Permanent Home), HV (Temporary), WP (Workplace),  MC (Mobile),  PG (Pager),  EC (emergency contact).  
• There is also an optional validTime child element to specify when the telecommunication address is stated to apply.

 

The result is that there are four flavours of Telecommunication Address:

1.     Telecommunication address (f)

2.     Telecommunication address plus use (f)

3.     Telecommunication address plus valid time (f)

4.     Telecommunication address plus use and valid time. (f)

 

All are described below.

 

1 value	The telecommunication number or address expressed as a URL.
0..* use	The following subset of the HL7 standard telecomm. addresses shall be used: "HP" - home “HV” - vacation or other temporary number) “AS” - an automatic answering machine “WP” - work “MC” - mobile number) “PG” - pager “EC” - emergency contact.
0..1 useablePeriod IVL<TS>	The period of validity of the address is specified using one of the following flavours of the IVL<TS> data type: Time Point - where known to be valid at a specified date. Time Interval Complete - where the start and end of the period of validity is known. Time Interval Before - where the end of the period of validity is known. Time Interval After - where the start of the period of validity is known.

 

Examples:

 

<!-- To indicate a home telephone number -->

<telecom use="H" value="tel:01392251289"/>

 

<!-- To indicate a work fax number -->

<telecom use="WP" value="fax:01392251689"/>

 

<!-- To indicate a mobile telephone number with from date -->

<telecom use="MC" value="tel:07700012345">

     <useablePeriod>

          <low value="20040401"/>

     </useablePeriod>

</telecom>

 

<!-- To indicate an e-mail address -->

<telecom value="mailto:joe.bloggs@myisp.co.uk"/>

2.5    Codes

2.5.1    Introduction

HL7 Version 3 supports four coded data types which can either be considered as constraints on the most flexible type (CD - Concept Descriptor) or extensions of the simplest type (CS -Coded Simple). The simplest form is merely a code, the more complex types add support for identifying the codeSystem, conveying textual renderings of the code meaning, adding translations from alternative code systems and adding qualifying codes to refined meaning.

The UK data type flavours for coded data types provide some additional levels of refinement to the coded data type hierarchy, for example in some flavours original text rendering are not just possible but are required.

The following subsections present the key features of each of the HL7 data types and are followed by the formal representations of the relevant UK data type flavours.

2.5.2    Concept Descriptor (CD)

An element of type CD may either have a NULL attribute or all three of: code, displayName and codeSystem.

The code attribute holds the code value, and displayName is the rubric associated with that code.  This is the text as provided by the maintainer of the code list, and must not be changed in any way by the sending system.  Where there is any difference in the text, this variation should be sent in the optional originalText attribute.  The codeSystem attribute must be supplied for all non-NULL instances of this data type, and is the OID for the coding system from which the code has been drawn.  See the HL7 specification for full details of the OID structure.

Two optional child elements allow code qualifiers ("qualifier" element) and alternate coding system representation of the same information ("translation" element).

 

Note that where a translation is used the original code used is expressed in the outer element. The translation element is used to send the required encoding. For example, the translation should be used to send a SNOMED CT concept identifier if clinical information was originally collected using some other coding system.

Note that this NPfIT specification pre-adopts a committee proposal for extension of the qualifier structure to allow grouping of qualifiers. This proposal has been pre-adopted to support accurate representation of SNOMED CT "role grouping".

The following flavours are valid constraints on this data type:

• Coded Plain
• Coded with Original Text
• Coded Qualified
• Coded Translated
• Coded, Qualified and Translated
• Coded Only
• Coded with Display Name
• Coded with Code System

 

2.5.3    Coded with Equivalents (CE)

CE is used where the approved coding scheme is not the original scheme in which the data was encoded. However, it is not applicable where qualifiers are required. The original code is mapped to a translated code in the approved scheme. The mapping may translate a specific original code to a more general code in the approved scheme but must not add specificity not present in the original code.

The following flavours are valid constraints on this data type:

·        Coded Plain

·        Coded with Original Text

·        Coded Translated

·        Coded Only

·        Coded with Display Name

·        Coded with Code System

 

2.5.4    Coded Simple Value (CS)

CS is used to convey information on the form of a code only.  This is only used where there is a short controlled list of possible values, and typically these will be HL7 defined structural codes where the coding system can reliably be inferred by context.

The following flavours are valid constraints on this data type:

·        Coded Only

 

2.5.5    Coded Value (CV)

CV is used where there is no requirement from sending translations or qualifiers, otherwise it has the same structure as the CD data type.  It must either have the NULL attribute, or all three of code, displayName, and codeSystem.

The following flavours are valid constraints on this data type:

·        Coded Plain

·        Coded with Original Text

·        Coded Only

·        Coded with Display Name

·        Coded with Code System

 

2.5.6    NPfIT

2.5.6.1     Coded Plain (f)

Valid constraint of HL7 data types: CD, CE and CV.

This flavour is used where the original encoding uses the approved coding scheme for a message attribute. It is the minimal flavour permitted where the message specifies the CD data type.

 

1 code	The primary code value originally used to encode a statement.
1 displayName	The text or rubric associated with the code.
1 codeSystem	An OID identifying the coding system from which the code is derived.

 

 Examples:

 

<!-- To indicate a request response for a "value" attribute of an observation class -->

<value code="11" codeSystem="2.16.840.1.113883.2.1.3.2.4.17.42" displayName="NHS Number confirmed"/>

 

2.5.6.2    Coded with Original Text (f)

Valid constraint of HL7 data types: CD, CE and CV.

This flavour is used where the original encoding uses the approved coding scheme for a message attribute but where there is some text entered or selected by the user that is not identical to the display text or rubric associated with the code.

 

1 code	The primary code value originally used to encode a statement.
1 displayName	The text or rubric associated with the code.
1 codeSystem	An OID identifying the coding system from which the code is derived.
1 originalText	The full text associated with this code as selected, typed or seen by the author of this statement. This may contain additional information that is not completely coded.   However, this should be avoided wherever possible - generally it should just be an alternative narrative expression of the coded information.

 

 Examples:

 

<!-- To indicate a code with the original text upon which the code was based for a "code" attribute of an observation class -->

<code code="195967001" codeSystem="2.16.840.1.113883.2.1.3.2.4.15" displayName="asthma">

    <originalText>currently suffering from asthma</originalText>

</code>

 

2.5.6.3                        Coded Qualified (f)

Valid constraint of HL7 data type: CD extended by pre-adoption of group element

The flavour is used where the approved coding scheme is also the original scheme in which the data was encoded and qualifiers from that scheme are also used to refine the meaning of the code

  

1 code	The primary code value originally used to encode a statement.
1 displayName	The text or rubric associated with the code.
1 codeSystem	An OID identifying the coding system from which the code is derived.
1 originalText	The full text associated with this code as selected, typed or seen by the author of this statement. This should usually convey the full meaning of the code and any qualifiers. It may contain additional information that is not completely coded. However, this should be avoided wherever possible.
0..* qualifier	Qualifiers are included only where these were used as qualifiers in the original encoding. Note that the codeSystem is not separately specified. It must be drawn from the same approved scheme as the primary code. Combinations of a single base coding scheme with different sets of qualifiers may be registered as distinct codeSystems if necessary to provide flexibility for local coding. 1 name CV Names the attribute qualifies the code (e.g. for "severity", "laterality") 1 code Code representing the name for this qualifying attribute. 1 displayName The display text or rubric associated with the name of this attribute. 1 value CD Specifies the qualifying value of the named attribute (e.g. for "mild" or "left"). 1 code The code representing the value of this qualifying attribute. 1 displayName The display text or rubric associated with the value of this attribute.
0..* group	1..* qualifier Qualifiers are included only where these were used as qualifiers in the original encoding. Note that the codeSystem is not separately specified. It must be drawn from the same approved scheme as the primary code. Combinations of a single base coding scheme with different sets of qualifiers may be registered as distinct codeSystems if necessary to provide flexibility for local coding. 1 name CV Names the attribute qualifies the code (e.g. for "severity", "laterality") 1 code Code representing the name for this qualifying attribute. 1 displayName The display text or rubric associated with the name of this attribute. 1 value CD Specifies the qualifying value of the named attribute (e.g. for "mild" or "left"). 1 code The code representing the value of this qualifying attribute. 1 displayName The display text or rubric associated with the value of this attribute.

 

2.5.6.4    Coded Translated (f)

Valid constraint of HL7 data types: CD and CE.

The flavour is used where the approved coding scheme is not the original scheme in which the data was encoded, but no qualifiers are used.

Note that the HL7 CE data type allows qualifiers for the translation although not for the original code. If qualifiers occur in the required code system then the Coded, Qualified and Translated  (f) (2.5.6.5) must be used. Thus there is no situation where there would be a requirement for the translation to be qualified unless there was also a need for the outer original code to be potentially qualified.

 

 

1 code	The primary code value originally used to encode a statement. If a particular coding scheme is required and is not the original scheme in which the message was encoded, this is represented in the translation.
1 displayName	The text or rubric associated with the code.
1 codeSystem	An OID identifying the coding system from which the code is derived.
1 originalText	The full text associated with this code as selected, typed or seen by the author of this statement.  It may contain additional information that is not completely coded on incompletely translated due to mismatch between the terminology models of the original and translated coding schemes.
1 translation CD	Map to Approved coding (e.g. SNOMED CT concept identifier) if other coding scheme is used in the primary code component (above). 1 code The code for this approved translation. Note that the code may require qualifiers (also from the approved scheme) to translate the primary code. 1 displayName The display text or rubric associated with the approved translation code. 1 codeSystem The OID of the approved/required coding system for this attribute.

 

 

Examples:

 

<!-- To indicate a code (Read 4 byte) with the original text on which the code was based together with a translation to another coding scheme (SNOMED CT). Note the original code is the outer element and the required translation is the inner element. -->

<code code=".H43." codeSystem="2.16.840.1.113883.6.28" displayName="asthma">

    <originalText>currently suffering from asthma""</originalText>

    <translation code="195967001" codeSystem="2.16.840.1.113883.2.1.3.2.4.15" displayName="asthma"/>

</code>

 

2.5.6.5    Coded, Qualified and Translated  (f)

Valid constraint of HL7 data type: CD extended by pre-adoption of group element

The flavour is used where the approved coding scheme is not the original scheme in which the data was encoded and where qualifiers were also used in the original encoding.  The original code and qualifiers are mapped to a translated code (with or without qualifiers) in the approved scheme. The mapping may translate a specific original coded expression to a more general coded expression in the approved scheme but must not add specificity that is not present in the original code.

 

1 code	The primary code value originally used to encode a statement. If a particular coding scheme is required and is not the original scheme in which the message was encoded, this is represented in the translation.
1 displayName	The text or rubric associated with the code.
1 codeSystem	An OID identifying the coding system from which the code is derived.
1 originalText	The full text associated with this code as selected, typed or seen by the author of this statement. This should usually convey the full meaning of the code and any qualifiers. It may contain additional information that is not completely coded. However, this should be avoided wherever possible.
0..* qualifier	Qualifiers are included only where these were used as qualifiers in the original encoding. Note that the codeSystem is not be separately specified. It must be drawn from the same approved scheme as the primary code. Combinations of a single base coding scheme with different sets of qualifiers may be registered as distinct codeSystems if necessary to provide flexibility for local coding. Note that individual qualifier components are not separately translated. The entire original coded expression is translated to the approved scheme. 1 name CV Names the attribute that qualifies the code (e.g. for "severity", "laterality") 1 code Code representing the name for this qualifying attribute. 1 displayName The display text or rubric associated with the name of this attribute. 1 value CD Specifies the qualifying value of the named attribute (e.g. for "mild" or "left"). 1 code The code representing the value for this qualifying attribute. 1 displayName The display text or rubric associated with the value of this attribute.
0..* group	1..* qualifier Qualifiers are included only where these were used as qualifiers in the original encoding. Note that the codeSystem is not separately specified. It must be drawn from the same approved scheme as the primary code. Combinations of a single base coding scheme with different sets of qualifiers may be registered as distinct codeSystems if necessary to provide flexibility for local coding. 1 name CV Names the attribute qualifies the code (e.g. for "severity", "laterality") 1 code Code representing the name for this qualifying attribute. 1 displayName The display text or rubric associated with the name of this attribute. 1 value CD Specifies the qualifying value of the named attribute (e.g. for "mild" or "left"). 1 code The code representing the value of this qualifying attribute. 1 displayName The display text or rubric associated with the value of this attribute.
1 translation CD	Map to Approved coding (e.g. SNOMED CT concept identifier) if other coding scheme is used in the primary code component (above). 1 code The code for this approved translation. Note that the code may require qualifiers (also from the approved scheme) to translate the primary code. 1 displayName The display text or rubric associated with the approved translation code. 1 codeSystem The OID of the approved/required coding system for this attribute. 0..* qualifier   The qualifier is option in the translation and is used only where necessary to qualify the meaning of the approved translation code so that it mirrors the meaning of the original code and original qualifiers. Note that the codeSystem is not be separately specified. It must be drawn from the same approved scheme as the translation code. 1 name CV Names the attribute that qualifies the code (e.g. for "severity", "laterality") 1 code Code representing the name for this qualifying attribute. 1 displayName The display text or rubric associated with the name of this attribute. 1 value CD Specifies the qualifying value of the named attribute (e.g. for "mild" or "left"). 1 code The code representing the value for the this qualifying attribute. 1 displayName The display text or rubric associated with the value of this attribute. 0..* group 0..* qualifier Qualifiers are included only where these were used as qualifiers in the original encoding. Note that the codeSystem is not separately specified. It must be drawn from the same approved scheme as the primary code. Combinations of a single base coding scheme with different sets of qualifiers may be registered as distinct codeSystems if necessary to provide flexibility for local coding. 1 name CV Names the attribute qualifies the code (e.g. for "severity", "laterality") 1 code Code representing the name for this qualifying attribute. 1 displayName The display text or rubric associated with the name of this attribute. 1 value CD Specifies the qualifying value of the named attribute (e.g. for "mild" or "left"). 1 code The code representing the value of this qualifying attribute. 1 displayName The display text or rubric associated with the value of this attribute.

 

2.5.6.6                        Coded Only (f)

Valid constraint of HL7 data types: CD, CE, CV and CS.

This flavour is use in most instances of the CS data type. Since this data type is only used for structural attributes and other attributes with fixed code list other components are not required.

 

1 code

The primary code value originally used to encode a statement.

 

Examples:

 

<!-- To indicate administrative gender of "Female" -->

<administrativeGenderCode code="2"/>

 

2.5.6.7    Coded with Display Name (f)

Valid constraint of HL7 data types: CD, CE and CV.

This alternative flavour may be required for use for some attributes, where there is a requirement for rendering displayable text without recourse to a lookup table within the stylesheet.

 

1 code	The primary code value originally used to encode a statement.
1 displayName	The text or rubric associated with the code.

 

 

2.5.6.8    Coded with Code System (f)

Valid constraint of HL7 data types: CD, CE and CV.

This alternative flavour may be required where there is a specified recognised coding system that can be looked up.

 

1 code	The primary code value originally used to encode a statement.
1 codeSystem	An OID identifying the coding system from which the code is derived.

 

Examples:

 

<!-- To indicate a confidentiality code of "Sensitive" -->

<confidentialityCode code="S" codeSystem="2.16.840.1.113883.2.1.3.2.4.16.1"/>

 

2.6    Identifiers

2.6.1    Instance Identifier (II)

The II data type only allows two attributes, a root and an extension. 

"Real world" identifiers such as a GMCP number or a patient NHS Number should be sent in the extension attribute, with the root being used to identify the assigning authority that is responsible for ensuring the uniqueness of the identifier in the extension.

An alternative mechanism is used for identifiers that are used to maintain instances of information as that information becomes distributed as a result of messaging.  In this case there is no single authority that can be made responsible for maintaining the uniqueness, and so DCE UUIDs are used (Universally Unique IDs).  These must be generated in a way that ensures uniqueness, and be expressed as dash separated hexadecimal numbers. The DCE UUID is sent in the root attribute.

 

2.6.1.1                        Identifier Global (f)

The Identifier Global flavour is used for representing instances of information objects in the message. It consists of a single component containing a DCE UUID

 

1 root

DCE UUID

 

 Examples:

 

<!-- To indicate a DCE UUID for an "id" class attribute -->

<id root="BBBBE26A-A9D1-A411-F824-9F7A00A33757"/>

 

2.6.1.2    Identifier External (f)

The Identifier External flavour is used for externally specified identifiers for real world entities. It consists of two components one identifying the scheme of identifiers and the other containing the identifier itself.

 

1 root	OID identifying the scheme of identifiers
1 extension	Real-world-Identifier within the specified scheme.

 

Examples:

 

<!-- To indicate an identifier for an "id" class attribute (in this case a NHS number) -->

<id root="2.16.840.1.113883.2.1.4.1" extension="9999999484"/>

 

2.7    Quantities

2.7.1    Quantity (QTY)

An element of the abstract type QTY may be any one of the data types INT (integer), REAL (real), MO (money), TS (timestamp), PQ (physical quantity) and RTO (ratio of quantities) – for all except MO see above or below.  It shall be resolved to one of these more specific data types when an instance of a message using it is generated. It is also used in defining certain other data types, such as IVL (interval). This represents the global HL7 standard, and is not an NPfIT flavour.

 

 

2.7.2    Physical Quantity (PQ)

Physical quantities are expressed using the two attributes "value" and "unit".  Where the measurement was originally taken in a different unit, then this can be sent in addition using the "value", "code", "codeSystem" and "displayName" attributes of the "translation" child element.

 

2.7.2.1                        Quantity in Standard Units (f)

Valid constraint of HL7 data type: PQ.

This flavour of the physical quantity data type should always be used where the quantity is measured in a set of units encoded using the UCUM representation approved by HL7. If any other units are used one of the extended expresions must but used to represent the unit used within a translation element. A proposal to completely map unit representations from SNOMED CT into UCUM will facilitate use of this simple unambiguous form of representation in most cases..

 

1 value	The value as an integer or decimal (real) number in the approved units.
1 unit	The UCUM representation of the unit

 

Examples:

 

<!-- To indicate a percentage for the "value" attribute of an observation class -->

<value value="92.55" unit="%"/>

2.7.2.2                        Quantity in Alternative Units (f)

Valid constraint of HL7 data type: PQ.

This flavour of the physical quantity data type should be used where the quantity is converted into the approved UCUM representation from an original recording in an alternative set of recognised units.  This flavour is used for representing medication dose form quantities recorded using the dm+d coded units of measure.

  

1 value	The value as an integer or decimal (real) number in the approved units.
1 unit	The UCUM representation of the approved unit. If the quantity is a count or the approved unit is not known the UCUM non-unit value of "1" for unity should be used.
1 translation PQR	Map to alternative coded units. 1 value The value in the alternative units. 1 code The code for this approved translation. Note that the code may require qualifiers (also from the approved scheme) to translate the primary code. 1 codeSystem The OID of the approved/required coding system for this attribute. 0..1 displayName The text representation of the units as given in the codeSystem.

 

Examples:

 

 

<!-- To indicate a counted quantity in alternative units of 100 tablets -->

2.7.2.3                        Quantity in Arbitrary Units (f)

Valid constraint of HL7 data type: PQ.

This flavour of the physical quantity data type should be used only where the quantity is expressed in arbitrary units for which there is no recognised unit of measure. An example of this might be a medication supply order in which the quantity is expressed as a number of packs of a specific size; for example an order for "6 packets each containing 21 tablets of A and 7 tablets of B" .

 

1 value	The numeric value (this should be the same as originalValue and should ignored)
1 unit	1 (to indicate the UCUM non-unit value of "1" for unity)
1 translation PQR	Map to arbitrary units. 1 value The value in the arbitrary units. 1 originalText The text representation of the arbitrary units.

 

 Examples:

 

<!-- To indicate a counted quantity in arbitrary units -->

<value value="6" unit="1">

     <translation value="6">

          <originalText>packets each containing 21 tablets of A and 7 tablets of B</originalText>

     </translation>

</value>

 

2.7.3    Interval of Physical Quantities (IVL<PQ>)

A range of physical quantity can either be expressed using "low" and "high" child elements to define the bounds of the interval (if only one of these is sent, then the other is assumed to be unbounded), or by sending the "center" element to express a single quantity instead of a range.

Potentially each of the flavours shown here may be extended to replace the "Quantity in Standard Units (f)" flavour of PQ, with the extended flavours "Quantity in Arbitrary Units (f)" or "Quantity in Alternative Units (f)" (see 2.7.2.2 and 2.7.2.3).

2.7.3.1                        Quantity Value (f)

Valid constraint of HL7 data type: IVL<PQ>.

This flavour is used when there is a single value in an attribute that is able to contain an interval of quantity values. This is equivalent to Quantity in Standard Units.

 

1 center PQ	1 value	The value as an integer or decimal (real) number.
	1 unit	The UCUM unit code.

 

Examples:

 

<!-- To indicate a measurement result for a "value" attribute of an observation class -->

<value>

     <center value="3.6" unit="mmol/l"/>

</value>

2.7.3.2    Quantity Range (f)

Valid constraint of HL7 data type: IVL<PQ>.

This flavour is used to express a bounded range of possible quantity values.

 

1 low PQ	1 value	The minimum value as an integer or decimal (real) number.
	1 unit	The UCUM unit code.
1 high PQ	1 value	The maximum value as an integer or decimal (real) number.
	1 unit	The UCUM unit code.

 

Examples:

 

<!-- To indicate a quantity range for a "value" attribute of an observation class -->

<value>

     <low value="3.6" unit="mmol/l"/>

     <high value="5.3" unit="mmol/l"/>

</value>

2.7.3.3                        Quantity Greater than (f)

Valid constraint of HL7 data type: IVL<PQ>.

This flavour is used to express a range of possible quantity values with a known minimum but no known maximum

 

1 low PQ	1 value	The minimum value as an integer or decimal (real) number.
	1 unit	The UCUM unit code.

 

Examples:

 

<!-- To indicate a quantity range greater than a specific value for a "value" attribute of an observation class -->

<value>

     <low value="3.6" unit="mmol/l"/>

</value>

2.7.3.4                        Quantity Less than (f)

Valid constraint of HL7 data type: IVL<PQ>.

This flavour is used to express a range of possible quantity values with a known maximum but no known minimum

 

1 high PQ	1 value	The maximum value as an integer or decimal (real) number.
	1 unit	The UCUM unit code.

 

 Examples:

 

<!-- To indicate a quantity range less than a specific value for a "value" attribute of an observation class -->

<value>

     <high value="5.3" unit="mmol/l"/>

</value>

2.7.4    Ratio of Physical Quantities (RTO<PQ>)

A ratio of physical quantities is expressed using two child elements "numerator" and "denominator", both should be sent and are of type PQ.  They must both be expressed using the same units This represents the global HL7 standard, ands is not an NPfIT flavour.

 

1 numerator PQ	1 value	The value as an integer or decimal (real) number.
	1 unit	The UCUM unit code.
1 denominator PQ	1 value	The value as an integer or decimal (real) number.
	1 unit	The UCUM unit code.

 

 Examples:

 

<!-- To indicate a ratio of 1:128 for a "value" attribute of an observation class -->

<value>

     <numerator value="1" unit="1"/>

     <denominator value="128" unit="1"/>

</value>

 

2.7.5    Ratio of Integers (RTO<INT>)

A ratio of integers is expressed using two child elements "numerator" and "denominator", both of type INT. This represents the global HL7 standard, ands is not an NPfIT flavour..

 

1 numerator INT	The integer value of the numerator
1 denominator INT	The integer value of the denominator

 

Examples:

 

<!-- To indicate a ratio of 1:128 for a "value" attribute of an observation class -->

<value>

     <numerator value="1"/>

     <denominator value="128"/>

</value>

 

2.8    Dates and Times

 

2.8.1    Point in Time (TS)

The timeStamp is sent in the "value" attribute of this data type. Time stamp information is sent in a format that is simplest for the XML schema to validate, as follows:

YYYYMMDDHHMMSS[+|-ZZzz],  where YYYY is the year, MM the month, DD the day, HH the hour, MM the minutes, SS.the seconds and +|-ZZzz is the time zone offset in hours and minutes. Sections from the right of this representation may be left off to send an imprecise date, thus "2000" would be a valid value for TS, indicating sometime in the year 2000.  A timestamp precise down to the hour would be “2000040103”. A timestamp precise down to the second would look like "20000401031520". 

 

2.8.1.1                        Date and Time (f)

Valid constraint of HL7 data type:GTS,  IVL<TS> and TS.

The time can be truncated from the right, q.v. below

 

value

yyyymmddhhmmss.nn or yyyymmddhhmmss or yyyymmddhhmm or yyyymmddhh

 

Examples:

 

<!-- To indicate an effective time of 12:05 on 25/06/2004 -->

<effectiveTime value="200406251205"/>

 

2.8.1.2                        Date Only (f)

Valid constraint of HL7 data type:GTS,  IVL<TS> and TS.

Use where time is not relevant, e.g. 5^th June2002 - “20020605”

 

value

yyyymmdd

 

Examples:

 

<!-- To indicate an effective time of 25/06/2004 -->

<effectiveTime value="20040625"/>

 

2.8.1.3                        Date Month (f)

Valid constraint of HL7 data type:GTS,  IVL<TS> and TS.

Use where date is approximate - i.e. sometime in June 2002 "200206"

 

value

yyyymm

 

Examples:

 

<!-- To indicate a birth time in June 2004 -->

<birthTime value="200406"/>

 

2.8.1.4                        Date Year (f)

Valid constraint of HL7 data type:GTS,  IVL<TS> and TS.

Use where date is very approximate and only known to year.

 

value

yyyy

 

 Examples:

 

<!-- To indicate a birth time in 2004 -->

<birthTime value="2004"/>

 

 

2.8.2    Interval of Points in Time (IVL<TS>)

A time interval can either be expressed using "low" and "high" child elements to define the bounds of the interval (if only one of these is sent, then the other is assumed to be unbounded), or by sending the "center" element to express a single point in time, or finally the "width" element can be used to express a duration which is not fixed to a particular point in time. 

The "width" would be used to state that a symptom lasted for 30 minutes, without having to state the exact time that this occurred. 

Note that if both "center" and "width" are present, then neither "low" nor "high" may be included.

 

2.8..2.1                        Date or Time Point (f)

Valid constraint of HL7 data type:GTS,  IVL<TS>.

This flavour should be used where the IVL<TS> data type is specified but only one date/time is known and it is not clear that this represents either the start or end of the event. Note the date/time need not be precise.

 

1 center

The date or time of the event - assuming it is not known to be specifically the start or end. It should not be assumed as the literal mid point. May be expressed as any flavour of Point in Time.

 

Examples:

 

<!-- To indicate an effective time of 12:05 on 25/06/2004 -->

<effectiveTime>

     <center value="200406251205"/>

</effectiveTime>

 

2.8.2.2                        Date or Time Interval Complete (f)

Valid constraint of HL7 data type:GTS,  IVL<TS>.

This flavour of should be used for any period of time with a known start and a known end. Note these start and end times need not be precise. 

 

1 low	The date or time when an event started. May be expressed as any flavour of Point in Time.
1 high	The date or time when an event ended. May be expressed as any flavour of Point in Time.

 

Examples:

 

<!-- To indicate an effective time between of 12:05 and 12:20 on 25/06/2004 -->

<effectiveTime>

     <low value="200406251205"/>

     <high value="200406251220"/>

</effectiveTime>

 

2.8.2.3                        Date or Time Interval After (f)

Valid constraint of HL7 data type:GTS,  IVL<TS>.

This flavour of should be used for any period of time with a known start but an unknown (or indefinite) end point. Note the start time need not be precise.

 

1 low

The date or time when an event started. May be expressed as any flavour of Point in Time.

 

Examples:

 

<!-- To indicate an effective time after 12:05 on 25/06/2004 -->

<effectiveTime>

     <low value="200406251205"/>

</effectiveTime>

 

2.8.2.4                        Date or Time Interval Before (f)

Valid constraint of HL7 data type:GTS,  IVL<TS>.

This flavour of should be used for any period of time with a known end point but an unknown starting time. Note these end time need not be precise.

 

1 high

The date or time when an event ended. May be expressed as any flavour of Point in Time.

 

Examples:

 

<!-- To indicate an effective time before 25/06/2004 -->

<effectiveTime>

     <high value="20040625"/>

</effectiveTime>

 

2.8.2.5                        Date or Time Duration Unanchored (f)

Valid constraint of HL7 data type:GTS,  IVL<TS>.

This flavour of should be used to express a duration where the actual time is unknown or unimportant. (e.g. a one month course of treatment).

ISSUE: The current HL7 approach is to use PQ instead of IVL<TS> because an unanchored duration is not considered to be a true point in time.

 

1 width, i.e. the duration of the event.	1 value	A period of time
	1 unit	A unit of time.

 

Examples:

 

<!-- To indicate an effective time of one month duration -->

<effectiveTime>

     <width value="1" unit="mo"/>

</effectiveTime>

 

2.8.2.6                        Date or Time Duration Anchored (f)

Valid constraint of HL7 data type:GTS,  IVL<TS>.

This flavour of should be used to express a duration where rough time is known (e.g. a 24 hour urine collection on 15 June 2002).

In theory two further - more precise - variants could be used with start or end times as anchor (e.g. "low" or "high"). However, for the purposes of this project a single solution for anchored time durations is felt to be adequate. Therefore, for an event of known start time and known duration (e.g. an appointment) - the Time Interval Complete flavour should be used specifying the start and end times allowing the duration to be computed.

 

1 center	The date or time when an event started. May be expressed as any flavour of Point in Time.
1 width, i.e. the duration of the event.	1 value	A period of time
	1 unit	A unit of time.

 

Examples:

 

<!-- To indicate an effective time with a 24 hour duration centred on 15/06/2002 -->

<effectiveTime>

     <center value="20020615"/>

     <width value="24" unit="h"/>

</effectiveTime>

 

2.8.3    General Timing Specification (GTS)

A set of points in time, specifying the timing of events and actions and the cyclical validity-patterns that may exist for certain kinds of information, such as phone numbers (evening, daytime), addresses (so called "snowbirds," residing closer to the equator during winter and farther from the equator during summer) and office hours.

 

NOTE: A GTS is nothing else than a SET<TS>. 

 

This represents the global HL7 standard, and is not an NPfIT flavour 

 

Please refer to Appendix A.2 of the XML ITS section of the HL7 ballot 6 for more information on this datatype.

 

• CR-0541: Section 2.4.4 - Postal Address (AD): Added value 'H' to the list of permitted values of the 'use' attribute.